A telecommunications network is composed of a variety of components. In addition to routers, signal-control points, and hubs, switches are ubiquitous components found in almost all communications networks. Switches process configuration transactions. Transactions can perform a variety of tasks. A transaction may be as simple as an entry or update in a database or as complex as processing a set of sequences that perform an ultimate task. As is appreciated in the art, a typical task for a transaction to complete is to add, delete, or otherwise modify data in a switch table.
Two types of data are common in a telecommunications-network environment: business data and administrative or transaction data. As used herein, business data refers to longer-term data that describes physical aspects of a network. Exemplary business data includes NPA-NXX codes, switch identifiers, trunk identifiers, trunk-group identifiers, station ranges, point of presence identifiers, network-element addresses, component locations, and the like. Transaction data is short-term data substantially limited to the lifespan of a transaction. Exemplary transaction data includes data such as a transaction ID, a time stamp, a status identifier, request information, a requestor's name, etc. Historically, business data has been stored in the same tables as transaction data. Although such a scheme may have been adequate for simple communications networks, it is an inefficient data model that suffers from several disadvantages that are exemplified in a complex communications network.
A first problem associated with storing business data and transaction data in a common table is data duplication. That is, data is unnecessarily repeated across many tables. For instance, a first table may store a transaction ID, a time stamp, and a first parameter. For certain business reasons, a second table may store the same transaction ID and maybe even a time stamp, but a second parameter. Historically, data has been stored in different databases to suit the needs of a communications carrier. For example, data associated with communications feeds has been maintained separately from business data, which has in turn been maintained separately from switch data. To the extent a table stores business data along with transaction data, then as the transaction data changes, the table or tables must also be updated, which leads to a second problem with storing business data with transaction data: updating tables is difficult.
If a first table having transaction data needs to be updated, then so too do all tables that share that common transaction data. Thus, either a user or application would need to update several tables associated with only a single change. Moreover, updating tables that share transaction data with business data is difficult because the data types of the various tables may be different. For example, a transaction ID field of a first table may be formatted to receive numerical input only. But a transaction ID field of a second table may be configured to accept data as a text string. Thus, to update both tables with a new transaction ID, the data would first need to be formatted as a number and then formatted as a text string. In other situations, data masks may be applied in some tables but not in other tables. In still other situations, a data field of a first table may accept data having a certain number of digits, while a sister table may accept data associated with the same field but require a different number of digits. Thus, having to reconcile multiple formats for the same data file types was a laborious and time-intensive task.
A third problem associated with grouping transactional data with business data relates to fault recovery. Historically, recovering from an error transaction has been complicated by a lack of information available. In order to recover from an error transaction, one needs to know where the transaction failed so that it can be started up again at that point. However, determining where a transaction failed using methods available in the prior art has not allowed analysts to precisely determine where a transaction has failed, which highlights a fourth shortcoming of the prior art. The prior art does not offer the ability to establish an audit trail associated with a transaction's progress.
Traditionally, old status data has been overwritten with new status data. Overriding status data deprives an analyst of visibility as to prior happenings within the switch. The lack of ability to establish an audit trail removes the ability for a user to identify at what point during a transaction's progression the transaction failed. Moreover, without an audit trail, no metrics associated with transaction-processing characteristics can be gleaned; this makes inefficiencies difficult if not impossible to identify and prohibits benchmarking for users. That is, no evaluation can be made at a user level.
The prior art could be improved by providing a system and method for maintaining a record of transaction data related to but separate from business data in a telecommunications-networking environment.